Entities often generate and use data that is important in some way to their operations. This data can include, for example, business data, financial data, and personnel data. If this data were lost or compromised, the entity may realize significant adverse financial and other consequences. Accordingly, entities typically back up their important data so as to create a backup that can later be used in a data restore process if necessary. Backup processes are not without their problems however, and sometimes events such as transient failures occur that can interrupt the backup. Some attempts have been made to address circumstances such as these but, for various reasons, have not proven to be satisfactory.
Some backup processes, one example is the EMC NetWorker Checkpoint Restart (CPR), are save path-based. That is, when the backup restarts after the occurrence of a transient failure, the backup process picks up where it left off. However, this approach does not work well in all circumstances. For example, some backups, such as Windows VSS-based backups for example, require the entire backup to be made from the same snapshot.
Another problem with save path-based backups concerns the backup path itself. In particular, during the time that has elapsed between the failure and the backup restart, the paths already saved could have changed. Consequently, the changes to the path already saved will not be part of the resultant saveset produced by the backup process. This problem is particularly concerning where it comes to backups generated for use in bare metal restore processes (BMR). In these types of backups, the backup of every volume in a targeted set of volumes has to be repeated even if the backup of only a single volume in the targeted set of volumes fails. This approach to backup restart results in a significant waste of both time and backup space. It is for this reason that some path-based backup platforms, such as EMC NetWorker Checkpoint Restart, are disabled for All and DISASTER_RECOVERY.
Path-based backup processes experience other problems as well. For example, problems can occur when more than one save stream is employed for the backup. An example of such a multiple save stream process is a dynamic parallel save stream (DPSS), where multiple save sets are created for a savepoint. Conventional processes may not define how and where the retry should be picked up in the restart after a backup fail has occurred.
In light of the foregoing, it would be useful to be able to restart a backup, after a failure has occurred, without backing up data that was already backed up in the initial saveset that was created prior to the failure. As well, it would be useful to be able to combine the partial saveset created prior to failure with the partial saveset created after restart of the backup to form a complete backup image that would be substantially the same as, or identical to, a new saveset retaken at the time of the restart.